Web sites, or Internet sites, very often provide information, products, services, or the like to their users. Many web sites require users to “register” before their web servers will grant access to the users. During registration, a user typically supplies personal information such as username, account number, address, telephone number, e-mail address, computer platform, age, gender, and/or hobbies to the registering web site. The registration information may be necessary to complete transactions (e.g., commercial or financial transactions). Typically, the information also permits the web site to contact the user directly (e.g., via e-mail) to announce, for example, special promotions, new products, or new web site features. Additionally, web sites often collect user information so web site operators can better target future marketing activities or adjust the content provided by the sites.
When registering a user for the first time, a web site typically requests that the user select a login ID and an associated password. The login ID allows the web site to identify the user and retrieve the user's information during subsequent user visits to the web site. Generally, the login ID must be unique to the web site such that no two users have the same login ID. The password associated with the login ID allows the web site to authenticate the user during subsequent visits to the web site. The password also prevents others (who do not know the password) from accessing the web site using the user's login ID. This password protection is particularly important if the web site stores private or confidential information about the user, such as financial information or medical records.
If the user visits several different web sites, each web site may require entry of similar registration information about the user, such as the user's name, mailing address, and e-mail address. This repeated entry of identical data is tedious when visiting multiple web sites in a short period of time. Many web sites require the user to register before accessing any information provided on the site. Thus, the user must first enter the requested registration information before he or she can determine whether the site contains any information of interest.
After registering with multiple web sites, the user must remember the specific login ID and password used with each web site or other Internet service. Without the correct login ID and password, the user must re-enter the registration information. A particular user is likely to have different login IDs and associated passwords on different web sites. For example, a user named Bob Smith may select “smith” as his login ID for a particular site. If the site already has a user with a login ID of “smith” or requires a login ID of at least six characters, then the user must select a different login ID. After registering at numerous web sites, Bob Smith may have a collection of different login IDs, such as: smith, smith1, bsmith, smithb, bobsmith, bob_smith, and smithbob. Further, different passwords may be associated with different login IDs due to differing password requirements of the different web sites (e.g., password length requirements or a requirement that each password include at least one numeric character and/or at least one uppercase character). Thus, Bob Smith must maintain a list of web sites, login IDs, and associated passwords for all sites that he visits regularly.
Although presently available multi-site user authentication systems permit a web user to maintain a single login ID (and associated password) for accessing multiple, affiliated web servers or services, further improvements are desired. For example, transactional communications between two or more web sites are at risk of tampering by a third party. When a user navigates from one web site to another, using a web browser, there is often a need to share state information between the two sites. A variation of this scenario occurs when one site initiates a transaction to be completed securely on another second site. One common way to deal with this variation is by passing query string parameters attached to the uniform resource locator (URL). In this instance, the parameters contain state and transaction elements. Unfortunately, this method is unreliable because the URL can be tampered with very easily and, thus, the state information may be destroyed. This is particularly problematic in the transactional case (i.e., when one wants to ensure that a transaction is not completed on the second site unless it was truly initiated on the first site).
In addition, it is also important to that the transaction not be vulnerable to a replay attack in which the URL is captured and resubmitted to gain improper access to another user's information. In other words, a good transaction completed on the second site should not be playable again unless it is properly initiated on the first site.
Although making a server-to-server call from one site to the other would ensure transactional integrity, it is understood by those skilled in the art that such a solution would be costly and have negative performance implications. For example, server-to-server transactions are not scalable because the server that initiates the state must also complete it and they have undesirable built-in latencies due to the need to maintain the state between the sites.
For these reasons, improved security is desired to minimize the risk of tampering and other attacks on site-to-site communications, including communications in a multi-site user authentication system.